Mobile networks fall into two categories, Frequency Division Duplexing (FDD), which uses two separated frequency bands to transmit/receive, and Time Division Duplexing (TDD), which transmits and receives on a single frequency band. Time synchronization (in addition to frequency synchronization) is needed for LTE-TDD, WiMAX TDD, CDMA networks (popular in North America), TD-CDMA and TD-SCDMA, while only frequency synchronization is required for LTE-FDD, GSM (global system for mobile communications), W-CDMA, and other wireless technologies. Even with the use of LTE-FDD, new LTE mobile services such as network MIMO and location-based services will demand accurate time synchronization.
The present invention has particular application to clock synchronization (both time and frequency) over packet networks, specifically with the synchronization of telecom networks. Unlike IT computing systems and sensor networks, which require millisecond level accuracies to operate well, telecom networks require sub microsecond (in fact, nanosecond) level accuracies. Such stringent clock quality levels have traditionally been provided by GPS, atomic clocks, and TDM timing links. For these reasons, the ITU-T, IEEE, and other standards bodies have defined special standards to allow packet networks to support the special synchronization needs of telecom networks. One such recent standard that is now widely accepted and adopted by the telecom industry is the IEEE 1588 Precision Timing Protocol (PTP). There is even a special IEEE 1588 profile defined for telecom applications. Even though time synchronization for IT computing systems and sensor networks have the same underlying concepts, these systems have different application requirements, protocols, architectures, and implementation goals and therefore considered completely out of scope of telecom synchronization.
IEEE 1588 is now the industry accepted packet-based method/standard for distributing timing information from a master to enable the clocks of distributed systems to be synchronized with high precision (accuracies in the nanosecond levels). Its underlying principle is a master/slave concept based on the regular exchange of synchronization messages as shown in FIG. 1, whereby a slave clock 5 in a slave device 3 is synchronized to a master clock 4 in a master device 1 by the exchange of messages over the packet network 2.
IEEE 1588 synchronizes all clocks within a network by adjusting clocks to the highest quality clock (GrandMaster clock). IEEE 1588 supports both frequency and time transfer unlike another packet-based technique called Synchronous Ethernet with supports only frequency transfer. IEEE 1588 defines a wide range of synchronization capabilities except the clock recovery mechanisms (servo algorithm, PLL, timers, etc.) to be used at the slave (client) to synchronize its local clock to the master.
In the case where clock transfers have to be done end-to-end with no assistance from the packet network (for example in the form of hop-by-hop Boundary Clocks (BCs) [1][2] or Transparent Clocks (TCs)), there are no reference clocks traceable to a Primary Reference Clock (PRC) at both ends of the packet network, or in the absence of a network-wide GPS service, a receiving timing-dependent terminal node has to use an adaptive timing technique to reconstruct the timing signal of the transmitting timing reference source. The receiving terminal would commonly use a “packet-based” clock recovery mechanism that slaves the receiver clock to a transmitter clock. The clock recovery mechanism is able to process transmitted clock samples (timestamps) encoded within the packet data stream to generate timing signal for the receiver. The purpose of the clock recovery mechanism is to estimate and compensate for the frequency drift occurring between the oscillators of the transmitter clock and the receiver clock. However, the presence of packet delay variation (PDV) and packet losses affects the performance of the clock estimation/compensation process, making the transmitter clock appear faster or slower than it actually is, and ultimately, causing the propagation of mostly wander up to the receiver clock signal. Wander is clock noise less 10 Hz while jitter is clock noise equal or greater than 10 Hz.
Basics of IEEE 1588 PTP
A clock whether physical or virtual can be used to associate an event with time. The time of a single event is called a timestamp and is a real number. In IEEE 1588v2 PTP messages are categorized into event and general messages. All IEEE 1588 PTP messages have a common header. Event messages are timed messages in that an accurate timestamp is generated at both transmission and receipt of each message. Event messages have to be accurately timestamped since the accuracy in transmission and receipt timestamps directly affects clock distribution accuracy.
General messages are not required to be timestamped. A timestamp event is generated at the time of transmission and reception of any event message. The set of event messages consists of Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp. The set of general messages consists of Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management, and Signaling. IEEE 1588 PTP allows for two different types of timestamping methods, either one-step or two-step. One-step clocks update time information within event messages (Sync and Delay-Req) on-the-fly, while two-step clocks convey the precise timestamps of packets in general messages (Follow_Up and Delay-Resp).
The Sync, Delay_Req, Follow_Up, and Delay_Resp messages are used to generate and communicate the timing information needed to synchronize ordinary and boundary clocks using the delay request-response mechanism. A Sync message is transmitted by a master to its slaves and either contains the exact time of its transmission or is followed by a Follow_Up message containing this time. In a two-step ordinary or boundary clock, the Follow_Up message communicates the value of the departure timestamp for a particular Sync message. A Delay_Req message is a request for the receiving node to return the time at which the Delay_Req message was received, using a Delay_Resp message.
The basic pattern of synchronization message exchanges for the two-step clocks are illustrated in FIG. 1. The message exchange pattern for the two-step clock can be explained as follows. The master 1 sends a Sync message to the slave 3 and notes the time T1 at which it was sent. The slave 3 receives the Sync message and notes the time of reception T2 according to its local clock 5. The master 1 conveys to the slave the timestamp T1 by one of two ways: 1) Embedding the timestamp T1 in the Sync message (not shown). This requires some sort of hardware processing (i.e., hardware timestamping) for highest accuracy and precision. 2) Embedding the timestamp T1 in a Follow_Up message as shown in FIG. 1. Next, the slave 3 sends a Delay_Req message to the master 1 and notes the time T3 at which it was sent. The master 1 receives the Delay_Req message and notes the time of reception T4. The master 1 conveys to the slave 3 the timestamp T4 by embedding it in a Delay_Resp message.
At the end of this PTP message exchange, the slave 3 possesses all four timestamps {T1, T2, T3, T4}. These timestamps may be used to compute the offset of the slave's clock 5 with respect to the master clock 4 and the mean propagation time of messages between the two clocks. The computation of offset and propagation time assumes that the master-to-slave and slave-to-master propagation times are equal symmetrical communication path.
Time/frequency can be transferred in an end-to-end fashion from master 1 to slave 3 without involving the intermediate network nodes 6 as illustrated in FIG. 2. In this scenario the slave 3 is solely responsible for correctly recovering the master clock signal. Compared to the other methods (e.g., using hop-by-hop Boundary Clocks or Transparent Clocks), time/frequency transfer here is more challenging because the slave 3 is exposed to all the PDV generated by the intermediate packet network 2 (FIG. 3 and FIG. 4). The processing and buffering of packets in network devices (switches, routers, etc.) introduces variations in the time latency of packets traversing the packet network 2 that tend to degrade the clock signal transferred. The PDV inherent in packet networks is a primary source of clock noise. The recovered clock from the PTP timing signal at the slave contains clock noise (contributed largely by PDV) that needs to be removed or attenuated. A filtering process is used at the slave to filter out the clock noise, thus generating a “smooth” clock output.